This section is intended to introduce the reader to various aspects of the art that may be related to various aspects of the present invention. The following discussion is intended to provide information to facilitate a better understanding of the present invention. Accordingly, it should be understood that statements in the following discussion are to be read in this light, and not as admissions of prior art.
Due to the broad adoption of service-oriented architectures, tools for composition, orchestration and choreography of services are gaining in popularity. The most well-known example of such tools is the BPEL, manifested by various tools, and the Windows Workflow Foundation. There exist also other approaches. For the sake of simplicity, but without the loss of genericity, we will use the term “application skeleton” for referring to a description defining structural, behavioural, execution and other major aspects of composite services For example, BPEL script can be an example of such an application skeleton.
Some 3rd party tools provide mechanisms for inspecting the source code and identifying any violations of a predefined coding style or certain coding guidelines. Most of these tools are based on the static analysis of the code, but there are also some tools that observe the dynamic behaviour of the code. Static tools are usually realized in form of a pre-processor that performs it checks, when being asked for it. AOP tool AspectJ is one example of the tool allowing for defining of such policies in form of aspects and controlling/altering the behaviour of Java compiler by their means.
Some systems use policies to control the execution of code. For example, Java Virtual Machines (JVM) use special policy files to control access to certain restricted APIs inside the code running on the given JVM.
Software developers often want to protect their programs from being copied (either physically or by borrowing the details of implementation) and/or executed without permission, since it would violate the license terms. There exist multiple mechanisms to protect the code:                Obfuscating the code        Providing the code only in the binary, compiled format, so that it is very difficult or impossible to restore the original source code from the binary form        
A set of well known mechanisms exists for controlling the actions that can be performed by the system based on an object being acted upon, party, type of action and other parameters. These mechanisms include different variations of Service Level Agreements (SLA) and subscriptions. It should be noted that user/party are used interchangeably herein and either refers to a party as a human being or another non-physical entity such as a program.
When creating new service compositions for e.g. very complex use-cases with non-trivial logic, it may be required to protect their source-code (or parts of it) from being accessed and/or modified by parties/customer, because it would preserve the know-how and/or also disallow any changes that make break the composition and lead to the unwanted and unexpected results. The last consideration is particularly important for the mission critical application, like those ones in the telecom domain, where telecom-grade stability is expected.
In the following text, without the loss of generality the term artifact denotes:                Basic entity being edited, controlled, transformed and executed by creation and execution environments        Or set of parts, where each part is a basic entity as defined previously or another artifactAn artifact may be an application skeleton, BPEL workflow definition, source code of the program or any other means of describing actions to be performed, structured document, etc.        
Without loss of generality an Execution Engine is a system capable of performing certain computer functions based upon the actions definitions described by the artifact. The computer functions can also be performed based on other information, whether it be internally or externally derived, or both, if so desired.
Current service creation environments and IDE have certain built-in policies regarding the ability of the party to access/create/modify/execute of the artifacts being controlled by these tools. This approach based on the build-in policies makes sense for the usual situation, where the source code is being developed by the party of the tool and where all the functions of the tool should be available for this party.
However, in a situation, where such artifacts are distributed in their source code (e.g. application skeletons), there is a need to have a more fine-grained control over the set of operations that could be performed on the artifact.
For example, the creator/owner of a composition may want to disallow any modification of it (or certain parts of it) or even prevent the definition of artifact from being able to be seen (i.e. it may be not possible to read it, but it could be possible to execute it).
Another interesting use-case could be in a case, where the developer, depending on her developer subscription for the given composition or creation environment as a whole, is not allowed to use certain parts of the IDE (i.e. menus, wizards) or even is not allowed to use/modify certain constructs of the language being used to define new artifacts.
Finally vendors of a composite service may want to sell application skeletons while maintaining control over them, so that they may not be modified by customers. Specific parts of such compositions may be editable or executable under specific conditions defined by the vendor (e.g. availability of special licenses). The set of operations that a customer is allowed to perform on the skeleton (i.e. read, modify, execute, export, etc) should be dependent on the agreement between the vendor and the customer (e.g. SLA, license, etc).
The use-cases described above cannot be expressed using service creation environments available today. Such tools rely mostly on the operating system and obey strictly to the security features the file system has to offer; for example read/write/execute access or group policies. The currently known solution for the provisioning of a variety of access features over different artifacts is the distribution of the functionality over different files. However, this solution makes it very difficult for the publisher to maintain each function and potentially leads to loss of the know-how contained within the application skeleton.